A single switch architecture is not scalable enough to support today's bandwidth hungry applications; therefore various multi-switch architectures have evolved, and the general theme among these architectures is a common interconnection mechanism between the various switches. That is, Ethernet switches are evolving from single devices to the large scale chassis with multiple line cards, blades, modules, “pizza boxes”, etc. As described herein, line cards, blades, modules, “pizza boxes”, etc. all refer to modules in an Ethernet switch and are collectively referred to herein as line cards. In one example, each line card in a chassis can be an individual switch although other embodiments can also be implemented. As described herein, the term line card can be used interchangeably for the term switch or interconnected switches. For example, individual line cards are each a switch, and the overall chassis or network element is a multi-switch architecture that is a single network element of the interconnected switches. From a network management/administrator's perspective, all these interconnected switches should give a singular switch view, e.g., it is not feasible to manage each line card as a separate network element. This architecture presents multiple challenges; one of them is a challenge of packet flooding as these switches' forwarding databases are not synchronized and thus media access control (MAC) address table lookup failures could cause flooding. Hence, if a MAC address is learned on say switch-A of an interconnect architecture and a stream with this resolved address starts from port that is on another switch (switch-B) then this stream's packets will get flooded.
MAC address learning is a service provided by a switch in which a MAC address and incoming interface information of each packet is learned locally and stored in a database on the switch. This service can be characterized as a learning bridge, in which a source MAC address of each received packet is stored in a forwarding database so that future packets destined for that address can be forwarded only to the bridge interface on which that address is located. Packets destined for unrecognized addresses are forwarded out every bridge interface. MAC address learning helps minimize traffic on the attached Local Area Networks (LANs). As Ethernet switch sizes evolve, maintenance of the forwarding database becomes significant. In the single device case, management of the forwarding database is straightforward in that all processing and storage circuitry related to the forwarding database is on the single device and in communication therein. As the large scale chassis develop, individual line cards have their own forwarding databases thereon that are managed, but need to be synchronized with other line cards in the same Ethernet switch. It is important to synchronize the forwarding databases between the line cards to avoid flooding when a MAC address has already been learned.
Conventionally, the multiple line card solution can include a central repository of the forwarding databases for all associated modules that is updated as and when required. However, this solution can cause the scalability issues especially in the case when the MAC address entries need to be synchronized on a periodic basis in case of topologies such as bridging over link aggregation. Multi-chassis architectures, therefore, employ a solution where line cards periodically update the MAC address in the peer line cards by a messaging mechanism. The messaging mechanism may either be implemented in software through some interprocess communications (IPC) mechanism or may be implemented in hardware (e.g., application specific integrated circuit (ASIC), network processor unit (NPU), field programmable gate array (FPGA), etc.). The hardware based periodic synchronization can utilize a lot of hardware bandwidth at timely intervals. As a result of which hardware switching capacity may exceed its total supported capacity and can result in periodic packet drops due to the synchronization. Among other things, this presents a challenge in meeting service layer agreements with end users.
Generally, conventional approaches to forward database synchronization include a control path forwarding approach and a data path forwarding approach. The control path forwarding approach uses the IPC mechanism for forwarding messages containing MACs to be synced, which is to be configured in a peer switch. The control path forwarding approach suffers from following drawbacks: inefficient and cumbersome software implementation, scalability becomes a challenge with increased IPC messaging, and processor load increases proportionally with large number of IPC call for large forwarding databases. The data path forwarding approach includes constructing a packet and sending it via the data path to its peer switches to trigger MAC learning. The data path forwarding approach suffers from following drawbacks: interference with data path bandwidth, and due to the interference, data path packet dropping can be encountered with large forwarding databases.
As switch architectures continue to grow, there is a need for an optimized approach for synchronizing forwarding database across multiple interconnected layer-2 switches such as a plurality of modules in a single chassis. An example of such an optimized approach is described in commonly-assigned U.S. patent application Ser. No. 14/275,920 filed May 13, 2014 and entitled “SYSTEMS AND METHODS FOR SYNCHRONIZING FORWARDING DATABASES ACROSS MULTIPLE INTERCONNECTED LAYER-2 SWITCHES,” the contents of which are incorporated by reference herein. The systems and methods disclosed in U.S. patent application Ser. No. 14/275,920 work perfectly for faceplate or logical Link Aggregation Groups (LAG) (i.e., member ports on a same switch or device), but do not work for logical distributed LAG ports (i.e., member ports on different switches or devices). With distributed LAG, for example, there needs to be a mechanism to determine whether a MAC is native or non-native to a particular switch.